home *** CD-ROM | disk | FTP | other *** search
/ Disc to the Future 2 / Disc to the Future Part II Programmer's Reference (Wayzata Technology)(6013)(1992).bin / MAC / THINKC / 4_0 / MUBBS_MO / STUFF_NO.TXT < prev   
Text File  |  1991-11-22  |  2KB  |  52 lines

  1. Here's some of the stuff I ran into so you don't have these problems:
  2.  
  3. Use >= more, not == because if a value is over it's limit for some STUPID programming reason, it fixes itsself instead of going crazy. If it's a IF statement that wants == thats NOT what I'm talking about. A "<=" doesn't take any longer in machine language to perform than "==" .
  4.  
  5. Don't use send("]"), use send(G->[u]). I'm about ready to make a define for this so it fixes this anyway.
  6.  
  7. Don't make structs like this unless you want them to be GLOBAL (and take up your DATA area):
  8.  
  9. typedef struct {
  10.                  int joe;
  11.                 } mystruct;
  12.  
  13. Make them like this:
  14.  
  15. typedef struct mystruct {
  16.                  int joe;
  17.                 };
  18.  
  19. Then you just do this:
  20.  
  21. proc() {
  22.  
  23. struct mystruct haha;
  24.  
  25. /* your code here */
  26. }
  27.  
  28. This makes a "mystruct" struct named "haha" ON THE STACK !
  29.  
  30. Call modules with mode 3 if you are passing a "user" struct.
  31.  
  32. Comment your code more, it's really hard to figure out what the HECK you are doing and takes HOURS longer than I have to to figure it out.
  33.  
  34. Please, PLEASE ! Close your files. Check CAREFULLY to see that you are closing your files at the proper place in your code. I have seen times where the file MAY close sometimes and other times it doesn't. There can only be so many files open at one time.
  35.  
  36. Don't make a module for EACH little bit of code you have. If it's that small, someone could just include YOUR code in theirs. If you think that there is a good reason for someone to call your "support" modules, then include them seperately. Most of the time they will need a "special" version of your code anyway.
  37.  
  38. You may want to add some "extras" to your structs, since you may have to live with the structs a while. You can't be shipping a new version every other week that bombs because others are depending on your structs.
  39.  
  40. THINK about your pointers and WHAT they are doing !! If your module crashes with a "address error" all the time, it's most likely a pointer !
  41.  
  42. *figure - means make a POINTER variable (not the value of the variable), you then make it POINT to something!
  43.  
  44. &figure means a POINTER that POINTS to "figure".
  45.  
  46. Think C (at least 4.0) handles the passing of STRUCTS ! So when you are working with structs, you need to know what Think C is doing with them ! Sometimes it passes a POINTER to the struct, sometimes it passes THE WHOLE STRUCT !
  47.  
  48. Don't use GLOBALS unless you REALLY have to, they get quite confusing when you think MULTI USER !!
  49.  
  50. -END-
  51.  
  52.